Fixes #36846 - Override REX job names for package install by search #10772
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What are the changes introduced in this pull request?
Previously, REX job names for bulk package installs were Katello database IDs, e.g. the description for the job would be "Install package(s) id ^ (2196)" or some such.
This change overrides that default description to actually display the package names, in most cases. (see considerations below)
Descriptions have been updated for
Considerations taken when implementing this change?
There are some .. nuances here. As you may know, we have a
useBulkSelect
React hook that allows us to store information about which items are selected. It can either be in "normal" mode, or "Select all" mode. The behavior changes depending on the mode."Normal" mode - A set of numeric IDs is stored (
selectionSet
), representing every item the user has selected. (These are typically the database ID, not the table row number.) This is how we start out. You can also click "select page" to select all items on the current page, and you'll remain in normal mode. Conveniently, when usingselectionSet
, we also record the selected items' other data, including package names in this case, and store it in a variable calledselectedResults
."Select all" mode - You can click the Select All checkbox to select all items on all pages. Since the front end hasn't yet downloaded the list of all the IDs for all pages, we don't yet know the complete list-- we just know that the user has indicated to select everything. When we enter "Select all" mode, we stop using the
selectionSet
and just say, "ok, everything is selected." But what if the user now wants to deselect some items? We then have to start populating anexclusionSet
, which you can think of as the opposite ofselectionSet
. It's basically saying that the user has selected everything except these IDs. However, when usingexclusionSet
we don't currently have the benefit of having storedselectedResults
.Long story short: In this PR, we take advantage of
selectedResults
to provide nice REX job descriptions where we can. So what about "Select all" mode?For errata REX jobs, this isn't as much of a problem because that already uses the somewhat more friendly "Errata ID" field, instead of the database ID.
What are the testing steps for this pull request?
To test this, you don't actually have to be able to communicate with the host. But you do have to have REX set up.
Test all of the scenarios and make sure you get the expected messages